Diameter is an authentication, authorization and accounting (AAA) protocol for computer networks, and is a successor to Radius. The Diameter base protocol is defined in International Engineering Task Force (IETF) request for comments (RFC) 6733 which is incorporated by reference herein in its entirety. Diameter messages use a per user framework and exist in the format of request-answer messages. Diameter answer messages travel back to the request source via the same path through which the request message was routed using hop-by-hop transport.
Diameter messages may be exchanged between Diameter nodes for performing various functions. For example, a mobility management entity (MME) and a home subscriber server (HSS) may interact for authentication, authorization, and/or accounting (AAA) purposes. Since communication networks use Diameter messages to perform a variety of functions, it is necessary to make sure Diameter nodes are working correctly and as expected, and to prevent and/or abate overload conditions from occurring at one or more Diameter nodes.
Diameter overload control is a mechanism by which a Diameter node indicates to other Diameter nodes that the reporting Diameter node is in an overloaded condition. The Diameter overload control mechanism may also be used to communicate existing load state information. Currently, there are two mechanisms proposed by the Diameter maintenance and extensions (DIME) working group of the Internet Engineering Task Force (IETF) for carrying and reporting overload conditions and load information within a network. The first mechanism is a piggy-backing mechanism that uses existing Diameter messages to carry overload conditions and/or load state information over the existing messages. This mechanism is specified in IETF Internet Draft draft-roach-dime-overload-ctrl-03, May 17, 2013, the disclosure of which is incorporated herein by reference in its entirety. The second mechanism uses Diameter application messages that are used only for communicating Diameter overload control information and/or load state information. This mechanism is specified in IETF Internet Draft draft-korhonen-dime-ovl-01.txt, Feb. 25, 2013, the disclosure of which is incorporated herein by reference in its entirety.
Using either mechanism, problems exist when overload conditions are not detected and/or reported quickly enough, resulting in one or more networks and/or elements thereof becoming slow, congested, and/or altogether stop working. Other problems occur when overload conditions onset quickly and/or occur suddenly. For example, when an abnormal event occurs within a highly populated area (e.g., a crime or tragic event occurs at a largely attended sporting event), people naturally reach for their phones to make emergency calls, exchange text messages, send/upload pictures, download videos, etc. This sudden onset of activity can overload networks and/or components thereof, and may cause the networks to get extremely sluggish and possibly fail.
Accordingly, in light of these difficulties, there exists a need for methods, systems, and computer readable media for predicting impending Diameter overload conditions using load information.